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Doscription 

Background o1 the Invention 

Field of the Invention 

This invention relates to a volume management 
system wherein the system using the volume manage- 
ment driver may also access a storage device directly 
without conflicting with the volume management sys- 
tem. 

More particularly, the invention relates to augment- 
ing the volume management driver in a UNIX operating 
system to add a capability to operate in a manner that 
allows the user to issue direct commands to a device 
through the volume management system drivers. 

Description of Related Art: 

In a UNIXoperating system there exist volume man- 
agement systems for devices particularly disk drive de- 
vices for managing the storage of information on optical 
or magnetic disk in a storage system. The volume man- 
agement software is part of the kernel in the UNIX op- 
erating system. The objective of this volume manage- 
ment software is to manage the storage media as op- 
posed to management of the storage device. For exam- 
ple, the volume management software would access 
storage media by name such as the volume name for a 
floppy disk In a diskette drive or for cylinders In a hard 
disk drive. Before volume management was available, 
a device driver in the UNIX kernel provided direct access 
to a device by the device name as for example, the A 
disk drive or the C disk drive. 

The present design of volume management system 
drivers is referred to as layered. As an example of op- 
erating in a layered volume management system. Fig. 
1 shows a read volume operation. Operation 1 1 from the 
application program (user) to the operating system ker- 
nel is "read A/ol," i.e. a request to read data from a lo- 
cation identified as a storage media volume. The proc- 
ess flows from the read request operation 11 from the 
user to the kernel of the UNIX operating system where 
a device driver at a first layer in the volume management 
system is the block device module "bdev_strategy 
(vol_dev)' 1 2. Device driver 1 2 at this first layer inter- 
prets the read operation for the volume and identifies 
the type (storage, printer, display, etc.) of device as 
specified by the ■(vol_dev)' parameters. The volume pa- 
rameters In this case identify a storage type of device. 
This first driver routine 12 calls module 14,"volstrategy 
(vol_dev)," at the next layer. Routine 12 knows that for 
vol_dev parameters received, it needs to call volstrategy 
(voLdev). Module 14 further Inteiprets voLdev param- 
eters received from module 1 2 and Identifies the storage 
device or storage system where the volume is located. 
The volstrategy module 14 then drives routine 16 back 
up at the device driver layer 1 2. Module 1 4 identifies the 



vol_dev number received as actual device number 'tp- 
>voLdev,' so it passes that to the block device driver 
routine 16, 'bdev_strategy(tp->vol_dev)." Routine 16 
Identifies a type of storage device, a hard disk drive, a 
s floppy disk drive or yet another storage system. In this 
example the device is a floppy disk drive or diskette 
drive. Routine 16 calls module 18 which is the floppy 
disk device driver for the diskette drive where the vol- 
ume is located. Module 18 Is the lowest layered level, 
and in this example module 18 is 'f dstrategy(fd_dev), ' 
a floppy disk driver routine. 

In this layered volume management system the de- 
vice that is ultimately opened and contains the volume 
being accessed is exclusively opened by the volume 
management system. Therefore, it is not possible for a 
direct access read operation such as 'read /device" op- 
eration 1 9 from the user to gain access to a device al- 
ready accessed by the volume management system. 
This is indicated In Fig. 1 by the blocked path between 
operation 19 and module IB. 

In the past users were not able to get direct access 
to a device, and were only able to access it through the 
volume management system, but first they had to go 
through a volume check command and then recite a 
path from the volume down to the device where the in- 
formation in the volume to be accessed was located. 
This level of complexity for the user to be able to access 
a device has prompted many users just to tum off vol- 
ume management and use only device direct access 
commands. What Is needed is the ability to have the 
UNIX operating system interpret both a volume man- 
agement access command from the user and a direct 
device access command from the user wrthout conflict. 

Direct access to a device through multiple layers of 
drivers is typically referred to in the art as stacked device 
drivers. In stacked device drivers the intermediate driv- 
ers are transparent. Accordingly, the read command 
from the user may proceed down the device driver layer 
and into the storage device driver layer without any vol- 
ume path specification by the user. What Is needed by 
the user might be referred to as a volume management 
system that Is both layered and stacked. 

The following background art relates in general to 
the problem of device or volume access conflicts in a 
UNIX environment. 

For example, EP-A-0,482,B53 is directed to a vol- 
ume management system in a UNIX environment. More 
particularly, it relates to maintaining a volume group sta- 
tus area to track updates to volumes in a volume group. 
However, It does not teach or suggest managing the 
combination of an open volume operative system and 
an open device operative system, as described and 
claimed in the present invention. 

IBM TECHNICAL DISCLOSURE BULLETIN, \AdI. 
34., No. 10A, March 1, 1992, pages 124-125 discloses 
a 'mechanism to allow cascaded device drivers to pass 
along select/poll I/O event requests." 

WO-A-91 1 9246 includes a description of a process 
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lor opening and closing a disk drive device. 

US-A-4,819,159 relates to a fault tolerant system 
building block (SBB) or nnanager where if there is a fail- 
ure by one such manager In control ('ownership') of a 
disk, then a second SBB takes over control of the disk. 

This background art does not contain a teaching of 
the management of both volume access requests and 
device access requests as described and claimed in the 
present Invention. 

Summary ot the Invention 

The present invention relates to apparatus and a 
method for managing the access to storage devices by 
user requests to a computing system, in accordance 
wrth claims 1 and 8, which follow. 

It is an object of this invention to provide a layered 
and stacked volume management system. 

In accordance with this invention, the above object 
is accomplished by a computing system operating a vol- 
ume management system for the storage of information 
and providing to the users of the volume management 
system parallel process paths for accessing a storage 
device as an access volume operation or as an access 
device operation. Further the volume management sys- 
tem prevents the two parallel logical operations from 
conflicting with each other by performing open volume 
operation and open device operation that indirectly com- 
municate by setting and clearing volume data. The vol- 
ume data Is meta-data that describes characteristics of 
the volume being accessed and the device being ac- 
cessed. The meta-data includes an open count and an 
exclusive flag to track the open status of a device. Open 
count indicates if the device is open, and the exclusive 
flag indicates whether the storage device has been 
opened exclusively by either the open volume or the 
open device operation request from a user. 

The inventive process Includes computer imple- 
mented steps of accessing a storage device through 
parallel processes - access volume process and ac- 
cess device process. The access volume process and 
the access device process both detect whether the re- 
quested storage device Is already open and whether or 
not its opened exclusively. This detection is accom- 
plished by testing for an exclusive flag In the volume da- 
ta for the device the user requested access to. Next the 
access volume process and the access device process 
test whether the request is an exclusive open request. 
These tests allow the parallel processes to maintain an 
open count and an exclusive flag for each storage de- 
vice. By monitoring the open count for non-zero and the 
exclusive flag, each process can return a busy code 
when the requested device is already exclusively open 
or the request is for an exclusive open, and the device 
has already been opened by a previous request that is 
still pending, i.e. has not been closed. 

The great advantage of this invention is that it per- 
mits a user to access storage devices either through an 



access volume operation or an access device operation. 
To the user either process is equally available and thus 
the user can operate both processes in parallel without 
concern for disabling or Inhibiting the volume manage- 
5 ment system. 

The foregoing and other objects, features and ad- 
vantages of the invention will be apparent from the fol- 
lowing more particular description of a preferred embod- 
iment of the invention as illustrated in the accompany 
drawings. 

Brief Description of Drawings 

Fig. 1 is a flow diagram of the layered volume man- 
agement system as it exists in the prior art. 

Fig. 2 is a flow diagram of a preferred embodiment 
of the invention, implementing both the layered and 
stacked volume management system to perform a read 
operation. 

Fig. 3 illustrates a computing system to perform the 
computer implemented steps in accordance with the in- 
vention. 

Fig. 4 shows a preferred embodiment for the open 
volume and open device processes and logical opera- 
tions of the invention. 

Fig. 5 shows the structure of the volume data indi- 
cating the open count and exclusive flag in the meta data 
making up the volume data. 

Fig. 6 shows the detailed operation flow of the vol- 
ume open process in Fig. 4. 

Fig. 7 shows the detailed operation flow of the de- 
vice open process in Fig. 4. 

Fig. 8 shows a preferred embodiment of the volume 
close and device close processes in accordance with 
the invention. 

Detailed Description of Preferred Embodiments 

The volume management system operations in- 
volve four primary operations -- open, read, write, and 
close. Each of these operations follow the parallel flow 
through layers of driver modules. In one process path, 
the layers are access volume process defined. In the 
other process path, the layers are access device proc- 
ess defined. The parallel process paths for read and 
write operations are independent process flows. How- 
ever, the parallel process paths for the open operation 
and the close operation must interact to deal with ac- 
cesses that require exclusive use of the device. 

As shown in Fig. 2, a preferred embodiment of the 
layered and stacked volume management system for 
the read operation is initiated by the user through either 
a read from volume operation 20 or a read from device 
operation 22. The read from volume operation 20 re- 
quest is passed to the device driver 'bdev_strategy 
(vol_dev)' module 24. In tum, the block device strategy 
module 24 calls a volume strategy module 26 based on 
the type of device identified in the vol_dev parameters. 
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The volume strategy driver 26 calls a device driver 
30 based on the device identified by the vol_dev. Block 
device strategy module 30 then calls the actual device 
strategy driven which In this case Is a floppy disk device 
driver module 32. 

In the process flow for the read from device opera- 
tion 22 from the user, operation 22 calls the block device 
strategy module 34 for a floppy disk device. This driver 
module 34 then drives a volume strategy driver module 
28 which calls the floppy disk strategy device driver 
module 32. In this way the layered process 24, 26, 30 
and stacked process 34, 28 for the volume management 
system operate in parallel. The write operation flow is 
identical to the read operation flow. 

The operating environment in which the present in- 
vention Is used encompasses the general distributed 
computing system, wherein general purpose comput- 
ers, workstations, or personal computers are connected 
via communication links of various types, in a client- 
sender arrangement, wherein programs and data, many 
in the form of objects, are made available by various 
members of the system. Some of the elements of a gen- 
eral purpose workstation computer are shown in Fig. 3, 
wherein a processor 1 is shown, having an input/output 
(I/O) section 2, a central processing unit (CPU) 3 and a 
memory section 4. The lyo section 2 is connected to a 
keyboard 5, a display unit 6, a disk storage unit 9 and a 
CD-ROM drive unit 7. The CD-ROM unit 7 can read a 
CD-ROM medium 8 which typically contains programs 
10 and data. The computer program products contain- 
ing mechanisms to effectuate the apparatus and meth- 
ods of the present invention may reside in the memory 
section 4, or on a disk storage unit 9, or on the CD-ROM 
8 of such a system. Examples of such systems include 
SPARC systems offered by Sun Microsystems, Inc., 
personal computers offered by IBM Corporation and by 
other manufacturers of IBM-compatible personal com- 
puters, and systems running the UNIX operating sys- 
tem. 

Before an access (read or write) operation may be 
performed as described above with reference to Fig. 2 
possible conflicts in access to the same storage device 
by either the read from volume operation 20 or the read 
from device operation 22 must be resolved by an open 
operation. The open operation as shown in Fig. 4 begins 
with either a user open volume request operation 36 of 
"open of device in Afol" or a user open device request 
operation 38 of "open of device in /dev." The volume 
open operation calls the ■dev_open(vol_path)' driver 
module 40. Dev_open Module 40 determines the device 
to be opened from the vol_path parameters and calls 
the ■volopen(vol_path)" driver module 42. Valopen mod- 
ule 42 tests for exclusive open status and tests for an 
exclusive open request received from the user's open 
volume operation 36. Volopen module 42 operates on 
the volume data 44 assigned to the device requested by 
the open request. Volopen module determines from the 
volume data If there are conflicts in open requests from 



open volume operation 36 and from open device oper- 
ation 38. 

In Fig. 4 the open requests from open device oper- 
ation 38 pass through ■dev_open(fd_path)' driver mod- 

5 ule 46 to ■vol_st_open(fd_path)' driver module 48. 
Dev_open Module 46 determines the device to be 
opened from the fd_path parameters and calls the 
■vol_st_open(fd_path)' driver module 48. VoLst_open 
module 48 |ust like volopen module 42 operates on the 

10 volume data 44 to resolve conflicts in open requests 
from open volume operation 36 and from open device 
operation 38. 

The structure of the volume data 44 is illustrated in 
Fig. 5 and the operation flow of volopen module 42 and 

IS vol_st_open module 48 are shown in Figures 6 and 7, 
respectively In Fig. 5, the volume data 44 structure is 
shown expanded as storage areas 44a. The volume da- 
ta comprises meta data that describes characteristics of 
the volume and device where the volume is located. The 

^0 characteristics of interest to the preferred embodiment 
of the invention are open count 50 and exclusive flag 
52. These characteristics are used by volopen module 
42 and vol_st_open module 48 to resolve conflicts in ac- 
cess to a device. 

In Fig. 6, the volopen process and logic operations 
for resolving conflicts are shown. When the volopen 
module is called, operation 53 reads the volume data 
characteristics from the volume meta-data for the re- 
quested device. Decision operation 54 first tests the vol- 

30 ume data 44 for an excl usive flag for the device. If there 
is an exclusive flag, the process branches to operation 
56, and operation 56 returns an EBUSY code to the vol- 
ume management system. The volume management 
would then process the next user operation request. If 

3S there is no exclusive flag set for the requested device, 
the process branches to decision operation 58. 

Decision operation 58 detects whether the volume 
open request from the user is an exclusive open re- 
quest. If the open request is not exclusive, the process 

-^0 branches to increment operation 60 to increase the 
open count in the volume data by one. Operation 61 
grants the open request, and a return success code 
goes to the operating system. 

If the open request is exclusive, the processes 

^5 branches YES from decision operation 58 to decision 
operation 62. Operation 62 tests whether the open count 
in the volume data characteristics is non-zero. If there 
is any count in the open count characteristic, operation 
64 returns an EBUSY code to the volume management 

50 system. In this situation, the device is already open, so 
an exclusive open is not possible at this time. If the open 
count is zero, the process branches NO from decision 
operation 62 to set operation 66. Operation 66 sets the 
exclusive flag in the volume data for the requested de- 

55 vice. Operation 60 then increments the open count char- 
acteristic, operation 61 grants the open request, and the 
volopen module operation for volume access process is 
complete. 
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II the user request was an open device request, the 
prcx;ess or logical operations are perlormed by 
vol_st_open module as shown in Fig. 7. When the 
vol_st_open module Is called, operation 67 reads the 
volume data characteristics lor the volume data as- 
signed to the requested device. Decision operation 68 
detects whether the volume data 44 contains an exclu- 
sive flag for the device. II there is an exclusive flag, the 
process branches YES to return operation 70. Opera- 
tion 70 returns an EBUSY code to the volume manage- 
ment system. II there is no exclusive flag set for the re- 
quested device, the process branches to decision oper- 
ation 72. 

Decision operation 72 tests if the device open re- 
quest from the user is an exclusive open request. It the 
open request is not exclusive, the process branches to 
increment operation 74 to increase the open count in 
the volume data by one. Operation 75 grants the open 
request, and a success code is returned to the operating 
system. 

If the open request Is exclusive, decision operation 
72 branches the process to decision operation 76. Op- 
eration 76 detects whether the open count in the volume 
data characteristics is non-zero. If there is a count in the 
open count characteristic for the device in the volume 
data, the process branches to operation 78 which re- 
turns an EBUSY code to the volume management sys- 
tem. If the open count is zero, the process branches NO 
from decision operation 76 to set exclusive flag opera- 
tion 80. Operation 80 sets the exclusive flag for the re- 
quested device in the volume data, and the process 
flows to 'clone me" operation 82. 

Clone me operation 82 changes the identification of 
the device to the host using system. This causes the 
using system to set another open count characteristic 
for the device even though the device being accessed 
is unchanged. The purpose of this cloning operation 
which sets a new open count characteristic is to create 
the appearance of a new device open count for each 
open device request from the user. In the UNIX operat- 
ing system, open device operations from the using sys- 
tem are sent for each open request. However if there 
are multiple accesses to the same device, the operating 
system only sends a close request once at the end of 
all the open operations, i.e. at the conclusion of the last 
access operation. Accordingly the volume management 
system when dealing with open device operations must 
have a mechanism to balance open requests and close 
requests. This is accomplished by the cloning operation 
82 which creates a pseudo device identity and thus vol- 
ume data for each open device request so that the op- 
erating system will send a close device request for each 
open device request when each access is completed. 
After the cloning operation 82, operation 74 increments 
the new open count characteristic forthe pseudo device 
to one, and the vol_st_open operation is complete. 

When the read or write access is completed forthe 
requested volume or device, close operations are sent 



by the user to the kernel of the UNIX operating system. 
The close operation is the same as the open operation 
as illustrated in Fig. 4 exceptthe drive modules are close 
modules. Also, the volclose(vol_path} operation and 
5 vol_st_close(fdjDath) are much simpler than volopen 
(vol_path) operation and the voLst_open(fd_path) op- 
eration. 

As illustrated in Fig. 8, the volclose operation and 
vol_st_close operation are identical. These processes 
only have to reset the open count characteristic and the 
exclusive flag characteristic of the volume data for the 
requested device. When either volclose or voLst_close 
are called, the process clears the open count in opera- 
tion 84 and clears the exclusive flag in operation 86. The 
volume management system is now ready to process 
further access requests to the device from user either 
by the volume access process or the device access 
process. 



1. In a computing system, apparatus for managing the 
access to storage devices by user requests (36, 38) 
to the computing system, said apparatus compris- 
ing: 

volume data (44) for each storage device 
stored in the computing system, said volume 
30 data including characteristics indicating the 

open status of each storage device; 
an open volume operative system (40) and an 
open device operative system (46) exchanging 
open status information for a storage device re - 
3S quested by a user through the volume data (44) 

for the requested storage device (32); 
said open volume operative system (40) re- 
sponsive to the volume data characteristics for 
testing whether the requested device is already 
-^0 open exclusively and whether the open volume 

request (36) from the user application is an ex- 
clusive open request; 

said open device operative system (46) respon- 
sive to the volume data characteristics for test- 
^5 ing whether the requested device is already 

open exclusively and whether the open device 
request (38) from the user application is an ex- 
clusive open request; 

said open volume operative system and said 
so open device operative system retum an open 

operation (42, 4S) successful to permit read or 
write access to the device by the computing 
system when each operative system detects 
that the requested device is not already exclu- 
^5 sively open or if the request is an exclusive 

open request that the device is not already 
open. 
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2. The apparatus of claim 1 , and in addition: 

said open volume operative system and said 
open device operative system return a busy 
code (56) to the computing system when the 
requested storage device Is already exclusively 
open (54) or when the requested storage de- 
vice is already open and the request is for an 
exclusive open (58) of the storage device. 

3. The apparatus of claim 1 or claim 2, wherein said 
volume data (44) includes an open indicator (50) 
and an exclusive open indicator (52) or exclusive 
flag for each storage device. 

4. The apparatus of claim 3, wherein the open indica- 
tor is an open count (60) incremented for each open 
request and wherein: 

said open volume operative system (40) and 
said open device operative system (46) test lor 
a non-zero count (62) to determine whether the 
requested storage device Is already open. 

5. The apparatus of claim 1 , wherein the characteris- 
tics in the volume data for each storage device in- 
clude an open count (50) indicating whether the 
storage device is open and an exclusive flag (52) 
indicating (54) whether the storage device is exclu- 
sively open. 

6. The apparatus of claim 5 wherein: 

each of said open volume operative system and 
said open device operative system detect (62) 
a zero open count and a request for an exclu- 
sive open, and grant (61) the request, and set 
(66) an exclusive flag in the volume data for the 
requested storage device. 

7. The apparatus of claim 6 wherein: 

each of said open volume operative system and 
said open device operative system detect a 
nonexclusive open request, grant the request, 
and increment (60) the open count for the re- 
quested storage device. 

8. A method for managing access to storage devices 
by user requests to a computing system comprising 
the steps of: 

storing a volume data (44) characteristic list for 
each storage device, the characteristic list indi- 
cating the open status of each storage device; 
in response to an open volume request (36) or 
an open device request (38), detecting (54) 
from the characteristic list whether the request- 



ed device is already exclusively open; and 
in response to an open volume request or an 
open device request, detecting (58) whether a 
request for a storage device Is an exclusive 
s open request and testing (62) the characteristic 

list to detect if the requested device is already 
open, whereby the avaiiabiiity of the storage 
device is determined. 

10 9. The method of claim B, and in addition the steps of: 

returning to the computing system a busy code 
(56) if the requested device is already exclu- 
sively open; and 
IS returning a busy code (64) to the computing 

system if the request is an exclusive open re- 
quest and the requested device is already 
open. 

^0 10. The method of claim B or claim 9, wherein the char- 
acteristic list includes an open count indicating the 
number of current open requests to each device 
and includes an exclusive flag indicating whether or 
not the device has been opened exclusively by a 

2S request. 

11 . The method of claim 1 0, and in addition the steps of: 

granting (61) an exclusive open request and 
30 setting the exclusive flag in the requested char- 

acteristic list if the requested device is not al- 
ready open; and 

setting the open count to non-zero In the re- 
quested characteristic list if the open volume 
3S request or the open device request is granted, 

whereby the access to a storage device may 
be requested either as a volume request or a 
device request and conflicts between the re- 
quests are managed. 



PatentansprOche 

1. Vorrichtung in einem Computersystem fur das Ma- 
^5 nagement des Zug riffs auf Speichergerate durch 
Benutzeranforderungen (36, 3B) an das Computer- 
system, wobei die Vorrichtung enthatt: 

Datentragerdaten (44) fur jedes Speichergerat, 
so die in dem Computersystem gespeichert sind 

und Eigenschaften umfassen, die den geoffne- 
ten Status Jedes Speichergerats angeben; 
e i n Dat ent rag e roff n u n g- Ausf u h ru n gssyst em 
(40) und ein Geratoffnung-Ausluhrungssystem 
ss (46), die Informationen bezuglich des geoffne- 

ten Status fur ein Speichergerat, das von einem 
Benutzer angefordert wird, anhand der Daten- 
tragerdaten (44) fur das angeforderte Spei- 
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chergerat (32) auslauschen; 
wobei das Datentrageroffnung-Ausluh rungs- 
system (40) auf die Datentragerdaten-Eigen- 
schalten anspricht, urn zu prufen, ob das ange- 
lorderte Gerat bereits exklusiv geoffnet ist und 
Ob die Datentrageroffnung-Anforderung (36) 
von der Benutzeranwendung eine exklusive 
Offnungsanforderung ist; 
wobei das Geratoffnung-Auslulirungssystem 
(46) aul die Datentragerdaten-Eigensciiaften 
anspriclnt, um zu prulen, ob das angelorderte 
Gerat bereits exl^lusiv gedlfnet ist und ob die 
Geratoffnung-Anforderung (38) von der Benut- 
zeranwendung eine exklusive Offnungsanfor- 
derung ist; 

wobei das Datentrageroffnung-Ausluli rungs- 
system und das Geratoffnung-AuGluhrungssy- 
stem eine Offnungsoperation (42, 48) zuruck- 
lerten, die erfolgreich einen Leseoder Sclireib- 
zugrrff auf das Gerat durch das Computersy- 
stem ermdgliclit, wenn jedes Ausfuhrungssy- 
stem erfaBt, dal3 das angeforderte Gerat niclit 
bereits ausscliiiel3iicli geoffnet ist Oder, talis die 
Anf order ung eine exklusive Offnungsanforde- 
rung ist, daB das Gerat nicht bereits geoffnet 
ist. 

2. Vorrichtung nach Anspruch 1 , wobei werterliin: 

das Datentrageroffnung-Ausfulnrungssystem 
und das Geratoffnung-Ausfuhrungssystem an 
das Computersystem einen Belegtcode (56) 
zurOckleiten, wenn das angeforderte Spelcher- 
gerat bereits exklusiv geoffnet ist (54) oder 
wenn das angeforderte Speicliergerat bereits 
geoffnet ist und die Anforderung auf ein exklu- 
sives dffnen (58) des Speichergerats zielt. 

3. Vorrichtung nacii Anspruch 1 oder 2, wobei die Da- 
tent rage rdaten (44) einen Offnungsanzeiger (50) 
und einen Exklusivoffnungsanzeiger (52) oder ei- 
nen Exklusivmerker fur jedes Speichergerat enthal- 
ten. 

4. Vorrichtung nach Anspruch 3, wobei der Offnungs- 
anzeiger ein dffnungszahlstand (60) ist, der bei je- 
der Offnungsanforderung inkrementiert wird, und 
wobei: 

das Datentrageroffnung-Ausfuhrungssystem 
(40) und das Geratoffnung-Ausfuhrungssy- 
stem (46) auf einen von null verschiedenen 
Zahlstand (62) prufen, um zu bestimmen, ob 
das angeforderte Speichergerat bereits geoff- 
net ist. 

5. Vorrichtung nach Anspruch 1, wobei die Eigen- 
Gchaften in den Datentragerdaten fur jedes Spei- 



chergerat einen Offnungszahler (50), der angibt, ob 
das Speichergerat geoffnet ist, sowie einen Exklu- 
sivmerker (52), der angibt (54), ob das Speicherge- 
rat exklusiv geoffnet ist, enthalten. 

5 

6. Vorrichtung nach Anspruch 5, wobei: 

sowohl das Datentrageroffnung-Ausfuh rungs- 
system als auch das Geratoffnung-Ausfuh- 

10 rungssystem einen Nu II -Offnungszah island 

und eine Anforderung fur ein exklusives Offnen 
erfassen (62), die Anforderung gewahren und 
in den Datentragerdaten fur das angeforderte 
Speichergerat einen Exklusivmerker setzen 

IS (66). 

7. Vorrichtung nach Anspruch 6, wobei: 

sowohl das Datentrageroffnung-Ausfuhrungs- 
^0 system als auch das Geratoffnung-Ausfuh- 

rungssystem eine nicht exklusive Offnungsan- 
forderung erfassen, die Anforderung gewahren 
und den Off nungszah island fur das angefor- 
derte Speichergerat inkrementieren (60). 

2S 

8. Verfahren fur das Management des Zugriffs auf 
Speichergerale durch Benulzeranforderungen an 
ein Computersystem, mil den folgenden Schrrtten: 

30 Speichern einer Eigenschaftsliste von Daten- 

tragerdaten (44) fur jedes Speichergerat, wobei 
die Eigenschaftsliste den geoffneten Status je- 
des Speichergerats angibt; 
als Anlworl auf eine Dalentrageroffnung-Anfor- 

3S derung (36) oder eine Geratoffnung-Anforde- 

rung (38) Erfassen (54), ob das angeforderte 
Gerat bereits exklusiv geoffnet ist, anhand der 
Eigenschaftsliste; und 

als Anlworl auf eine Dalentrageroffnung-Anfor- 
-^0 derung oder eine Geraloffnung-Anforderung 

Erfassen (58), ob eine Anforderung fur ein 
Speichergerat eine exklusive Offnungsanfor- 
derung isl, und Prufen (62) der Eigenschaftsli- 
ste, um zu erfassen, ob das angeforderte Gerat 
^5 bereits geoffnet ist, wobei die Verfugbarkeit des 

Speichergerats bestimmt wird. 

9. Verfahren nach Anspruch 8, weiterhin mil den fol- 
genden Schrrtten: 

50 

Zuruckleiten eines Belegtcodes (56) an das 
Computersystem, falls das angeforderte Gerat 
bereits exklusiv geoffnet isl; und 
Zuruckleiten eines Belegtcodes (56) an das 
ss Computersystem, falls die Anforderung eine 

Exklusivoffnungsanf orderung ist und das ange- 
forderte Gerat bereits geoffnet ist. 
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10. Verfahren nach Anspruch 8 oder Anspruch 9, wobei 
die Eigenschatt8li8te einen Off nungszah Island, der 
die Anzahl momentaner Offnungsanforderungen 
fur Jedes Gerat angibt, und einen Exlclusivmerlcer, 
der angiblp ob das Geral durcin eine Aniorderung 
exklusiv geoffnet worden ist, enthalt. 

11. Verfaiiren nacin Ansprucii 10, weiterhin mit den fol- 
genden Sclnritten: 

Gewaliren (61 ) einer Exklusivoffnungsanforde- 
rung und Setzen des Exiclusivmeriters in der 
angeforderten Eigenschaftsliste, falls das an- 
geforderte Gerat nicht bererts geoffnet ist; und 
Setzen des Offnungszahlers auf Nichtnull in 
der angeforderten Eigenscliaftsliste, falls die 
Datentrageroffnung-Anforderung oder die Ge- 
ratoffnung-Anforderung gewahrt wird, wobei 
der Zugriff auf ein Speichergerat entweder als 
Datentrageranlorderung oder als Geratanfor- 
derung angefordert werden kann und Konflikte 
zwischen den Anforderungen gemanagt wer- 
den. 



Revendlcotlons 

1 . Dispositif, faisant partie d'un systfeme informatique, 
destine a gerer I'acces a des dispositifs de mennoire 
par des demandes d'utilisateurs (36, 38) adress^es 
au systdme informatique, ledit dispositil compre- 
nant: 

des donnees de volume (44) pour chaque dis- 
positif de m^moire, m6moris6es dans le sysXb- 
me informatique, lesdites donnees de volume 
comprenant des caracteristiques indiquant 
I'^tat ouvert de chaque dispositif de m^moire; 
un systeme (40) operationnel d'ouverture de 
volume et un systdme (46) operationnel 
d'ouverture de dispositif eciiangeant une infor- 
mation d'etat d'ouverture pour un dispositil de 
m6moire demand^ par un utilisateur par I'inter- 
mediaire des donnees de volume (44) pour le 
dispositif de m^moire requis (32); 
ledit systeme operationnel d'ouverture de volu- 
me (40) r^agissant aux caracteristiques de 
donnees de volume pour verifier si le dispositif 
demande est deja ouvert de maniere exclusive 
et si la demande d'ouverture de volume (38) 
provenant de I'application d' utilisateur est une 
demande d'ouverture exclusive; 
ledit systeme operationnel d'ouverture de dis- 
positif (46) r^agissant aux caracteristiques de 
donnees de volume pour verifier si le dispositf 
demande est deja ouvert de maniere exclusive 
et si la demande d'ouverture de dispositif (38) 
provenant de I'application d' utilisateur est une 



demande d'ouverture exclusive; 
ledit systeme operationnel d'ouverture de volu- 
me et ledit systeme operationnel d'ouverture de 
dispositif renvoient une operation d'ouverture 

s (42, 4B) reussie pour permettre I'acces en lec- 

ture ou en ecriture au dispositif par le systeme 
informatique lorsque chaque systeme opera- 
tionnel detecte que le dispositif demande n'est 
pas dej^ ouvert de maniere exclusive ou, si la 

10 demande est une demande d'ouverture exclu- 

sive, que le dispositil n'est pas dej^ ouvert. 

2. Dispositif selon la revendication 1 , dans lequel, en 

outre: 

IS 

ledit systeme operationnel d'ouverture de volu- 
me et ledit systeme operationnel d'ouverture de 
dispositif renvoient un code d'occupation (56) 
au systeme informatique lorsque le dispositif de 
^0 memoire demande est deja ouvert de maniere 

exclusive (54) ou lorsque le dispositil de me- 
moirs demande est deja ouvert et que la de- 
mande se rapporte ^ une ouverture exclusive 
(58) du dispositil de memoire. 

2S 

3. Dispositif selon la revendication 1 ou la revendica- 
tion 2, dans lequel lesdites donnees de volume (44) 
comprennent un indicateur d'ouverture (50) et un 
indicateur d'ouverture exclusive (52), ou indicateur 

30 exclusif, pour chaque dispositif de memoire. 

4. Dispositif selon la revendication 3, dans lequel I'in- 
dicateur d'ouverture est un compteur d'ouverture 
(60) increments a chaque demande d'ouverture et 

3S dans lequel : 

ledit systeme operationnel d'ouverture de volu- 
me (40) et ledit systeme operationnel d'ouver- 
ture de dispositif (46) verrfient la presence 
-^0 d'une valeur non nulle (62) afin de determiner 

si le dispositif de memoire demande est deja 
ouvert. 

5. Dispositif selon la revendication 1 , dans lequel les 
4^ caracteristiques dans les donnees de volume pour 

chaque dispositif de memoire comprennent un 
compteur d'ouverture (50) indiquant si le dispositif 
de memoire est ouvert et un indicateur exclusif (52) 
indiquant (54) si le dispositif de memoire est ouvert 
50 de maniere exclusive. 

6. Dispositif selon la revendication 5, dans lequel: 

chacun dudit systems operationnel d'ouverture 
55 de volume et dudit systeme operationnel 

d'ouverture de dispositif detecte (62) un nom- 
bre d'ouverture nul et une demande d'ouverture 
exclusive, et accepts (61 ) la demande, et posi- 
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lionne (66) un indicaleur exclusrf dans les don- 
n6es de volume pour le dispositif de m6moire 
demande. 

7. Dispositif selon la revendication 6, dans lequel: 5 

chacun dudit systdme op6ralionnel d'ouverture 
de volume et dudit systeme operationnel 
d'ouverture de dispositif d^tecte une demande 
d'ouverture non exclusive, accepte la deman- 10 
de, et incr6mente (60) le compteur d'ouverture 
pour le dispositif de memoire demande. 

8. Proc6d6 de gestion d'accfes & des dispositils de me- 
moire par des demandes d'utilisateur a un systeme is 
informatlque comprenant les 6tapes de: 

memorisation d'une liste caract^ristique de 
donnSes de volume (44) pour chaque dispositif 
de memoire, la liste caracteristique indiquant 
I'Stat d'ouverture de chaque dispositif de me- 
moirs; 

en r6ponse ^ une demande d'ouverture de vo- 
lume (36) ou une demande d'ouverture de dis- 
positif (38), detection (54), a partir de la liste 
caract6rlstique, du lart que le dispositif deman- 
de est deja ouvert de maniere exclusive; et 
en r6ponse ^ une demande d'ouverture de vo- 
lume ou une demande d'ouverture de dispositif, 
detection (58) du fart que la demande pour un 30 
dispostif de m6moire est une demande 
d'ouverture exclusive et verification (62) de la 
liste caracteristique afin de detecter si le dispo- 
sitif demande est deja ouvert, de sorte que la 
disponibilite du dispositif de memoire est deter- 3S 
minee. 

9. Procede selon la revendication 6, comprenant, en 
outre, les etapes de: 

40 

renvoi, vers le systeme informatlque, d'un code 
d'occupation (56) si le dispositif demande est 
dej^ ouvert de maniere exclusive; et 
renvoi d'un code d'occupation (64) vers le sy- 
teme inlomiatique si la demande est une de- 
mande d'ouverture exclusive et que le dispositif 
demande est dej^ ouvert:. 

10. Procede selon la revendication 8 ou la revendica- 
tion 9, dans lequel la liste caracteristique comprend so 
un compteur d'ouverture indiquant le nombre de de- 
mandes d'ouvertures courantes pour chaque dispo- 
sitif et comprend un indicateur exclusif indiquant si 

le dispositif a ete ouvert: de manidre exclusive ou 
non par une demande. 55 

11. Procede selon la revendication 10, et comprenant, 
en outre, les etapes de: 



acceptation (61) d'une demande d'ouverture 
exclusive et positionnement de 1' indicateur ex- 
clusif dans la liste caracteristique demandes si 
le dispositif demande n'est pas dejSi ouvert; et 
positionnement du compteur d'ouverture a une 
valeur non nu lie dans la liste caracteristique de- 
mandee si la demande d'ouverture de volume 
ou la demande d'ouverture de dispositif est ac- 
ceptee, de sorte que I'acces h un dispositif de 
memoire peut etre demande sort comme une 
demande de volume sort comme une demande 
de dispositif et les conflits entre les demandes 
sont geres. 
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